Mantener la calidad de servicio en la nube

Los clientes esperan la misma calidad de servicio independientemente de que una determinada aplicación se ejecute sobre una infraestructura de nube o sobre una configuración tradicional de hardware nativo. Para satisfacer estas expectativas se requiere calidad en la implementación y una robusta arquitectura software de la aplicación. Requiere también una calidad de servicio aceptable de la infraestructura virtualizada de la nube, los componentes tecnológicos que la soportan y las redes que conectan al cliente con la aplicación.

¿Cómo juzgan los clientes la calidad de servicio de la aplicación?

Se utilizan unos Indicadores Clave de la Calidad KQI (“Key Quality Indicators”) para caracterizar la forma en que los clientes perciben la calidad de servicio de la aplicación. La naturaleza de estos indicadores KQI varía, a veces considerablemente, de una aplicación a otra. Un indicador que es crítico para una aplicación pueden tener una relevancia nula para otra aplicación. Sin embargo, hay algo que se mantiene en todas las aplicaciones: los indicadores KQI desempeñan un papel central para caracterizar los criterios que conforman la valoración y expectativas de los clientes con respecto a la calidad de servicio.

El problema de la calidad de servicio en la nube

Las aplicaciones alojadas en una infraestructura de nube se enfrentan a retos singulares de calidad de servicio. En la nube, la calidad de servicio que experimentan los clientes está influida por un procesamiento, memoria, almacenamiento y recursos de red virtualizados, facilitados por el proveedor de servicios de nube que aloja la ejecución del software de la aplicación. Está también influida por los componentes tecnológicos basados en la nube que contribuyen al servicio de la aplicación.

Estas capacidades relacionadas con los recursos añaden riesgos adicionales de degradación del servicio. Una aplicación puede tener que afrontar unos recursos no estables de la infraestructura debido a una pugna por los recursos o a fallos de la máquina virtual (VM) como, por ejemplo, una disminución de la velocidad o una finalización prematura. Estas perturbaciones pueden afectar a los clientes, degradando la calidad de servicio de la aplicación.

Un nuevo entorno implica nuevos retos

Para lidiar con los retos presentados por el procesamiento, memoria y almacenamiento virtualizados de la infraestructura de nube, muchas aplicaciones utilizarán componentes tecnológicos (por ejemplo, sistemas de gestión de base de datos y de reparto de carga) que son ofrecidos como un servicio por los proveedores de nube. Para tener éxito, las empresas que operan aplicaciones basadas en la nube deben tener la capacidad de detectar rápidamente cualquier degradación de la calidad de servicio de la aplicación, localizar el problema para detectar la causa raíz, restaurar el servicio del usuario y desplegar una acción correctora.

Desafortunadamente, no hay un enfoque único para resolver toda la problemática de la calidad de servicio. Para una aplicación concreta, la calidad de servicio del usuario puede ser sensible a determinadas degradaciones de la infraestructura y relativamente insensible a otras. Y lo que es más, diferentes aplicaciones y arquitecturas presentan sensibilidades diferentes. 

Degradaciones causadas al cambiar las responsabilidades

Los roles tradicionales y las responsabilidades cambian en la nube. Para crear un servicio, un proveedor de servicios de nube puede agrupar software, conexiones de red y “componentes como un servicio” de diferentes suministradores. Esto puede dificultar el seguimiento de los problemas y la determinación de quién es el responsable de solucionarlos.

Las métricas normalizadas para la calidad de servicio de la infraestructura de nube pueden ayudar a los proveedores de servicios y los usuarios de la nube a gestionar la inevitable degradación del servicio. Estas métricas pueden servir para identificar rápidamente el componente o servicio que ha fallado, de forma que el responsable pueda restaurarlo con rapidez y desplegar las acciones correctoras apropiadas. Con los indicadores KQI de infraestructura estándares, por ejemplo, un proveedor de servicios de nube puede negociar los Objetivos de Nivel de Servicio SLO (“Service Level Objectives”) requeridos para una determinada aplicación. El proveedor de servicios de nube puede también seleccionar el software y equipamiento de la infraestructura que mejor satisface estos requisitos, y gestionarlo para asegurar que alcanza o supera sistemáticamente los objetivos SLO definidos.

Degradaciones causadas por las nuevas asociaciones

Además del software de la aplicación, las instancias de la aplicación que se ejecutan sobre una infraestructura de nube se apoyan en componentes críticos proporcionados por diversos colaboradores para proporcionar una calidad de servicio aceptable para los clientes. Entre estos componentes se incluyen:

• Máquinas virtuales, que sustituyen al ordenador o servidor tradicional para proporcionar aplicaciones basadas en la nube. Al igual que el hardware tradicional, las instancias de máquinas virtuales son vulnerables y pueden fallar. No obstante, las instancias de máquinas virtuales son más vulnerables a disminuciones de velocidad, latencia variable en el acceso a los recursos, activación inconsistente de eventos, errores de reloj y otros tipos de degradaciones. Pueden deberse a la compartición de recursos y a la tecnología de virtualización subyacente, que introduce un nivel de emulación de hardware imperfecto entre el sistema operativo huésped de la aplicación y el hardware físico.
• Conectividad como un Servicio, que proporciona conectividad de red entre las instancias de la máquina virtual de la aplicación y los restantes elementos y sistemas distribuidos. Tradicionalmente los proveedores de servicios utilizaban el plano de conexión del equipo e infraestructuras de redes físicas para conectar los elementos hardware tradicionales. Los proveedores de servicios de nube deben ofrecer la conectividad de red como un servicio de modo que las aplicaciones distribuidas basadas en la nube puedan operar y aportar valor a los clientes. Estas ofertas de Conectividad como un Servicio son vulnerables a pérdidas de paquetes, latencia y jitter, y a degradaciones que afectan a la disponibilidad.
• Los componentes tecnológicos ofrecidos como un servicio, que pueden acortar el tiempo necesario para introducir una aplicación en el mercado y reducir los costes de operación. Las ofertas como “Base de Datos como un Servicio” y “Reparto de Carga como un Servicio” permiten a un proveedor de servicios de nube “contratar” un servicio de un componente tecnológico maduro sin necesidad de “construir” instancias privadas específicas para la aplicación. Sin embargo, estas ofertas son vulnerables a degradaciones de la fiabilidad, latencia, calidad e indisponibilidad del servicio.

Pasos necesarios para resolver la degradación

Hay tres acciones fundamentales con las que se puede comenzar a resolver las degradaciones de calidad de servicio que pueden causar las infraestructuras informáticas basadas en la nube a los usuarios de la aplicación. Estas acciones son:

1. Comprender que diferentes aplicaciones tienen diferentes sensibilidades de la calidad de servicio que percibe el cliente por la degradación de las prestaciones del proveedor de servicios de nube. Por ejemplo, la calidad de servicio de una aplicación orientada a procesamiento en lotes puede ser insensible a la pérdida de paquetes, latencia y jitter. Por el contrario, la calidad de servicio de aplicaciones altamente interactivas puede ser muy sensible a las mismas perturbaciones.
2. Diseñar una arquitectura de las aplicaciones que minimice el impacto en el cliente final de las degradaciones de servicio de la infraestructura de nube. Asimismo, probar las aplicaciones en situaciones con gran probabilidad de degradación de servicio para asegurar que los clientes reciben sistemáticamente una calidad de servicio aceptable.
3. Reconocer que una línea de separación bien definida hace buenos vecinos. Acuerde los objetivos SLO para todos los indicadores KQI de la infraestructura de nube de forma que se puedan aislar los fallos rápidamente cuando haya una degradación de la calidad de servicio del usuario. Una correcta definición de la línea de separación y los requerimientos del servicio simplificará la localización de problemas y determinará quién es el responsable de solucionar la causa raíz.

Definición de objetivos alcanzables

Al igual que con las aplicaciones desplegadas tradicionalmente, es inevitable que las aplicaciones basadas en la nube experimenten ocasionalmente fallos y degradaciones del servicio. El objetivo debería ser desplegar aplicaciones robustas y económicas sobre la infraestructura de nube, y asegurar que habitualmente se cumplen o se superan las expectativas del cliente de calidad de servicio.

Esto significa asegurar que una determinada aplicación puede detectar, mitigar y resolver rápidamente el impacto causado en el servicio por degradaciones originadas en infraestructuras informáticas basadas en la nube. Significa también identificar claramente los roles y responsabilidades de los proveedores de software, de infraestructura y de la plataforma como un servicio. Incluyendo técnicas de negocio que implanten objetivos SLO cuantitativos para cada responsable, aplicando métricas normalizadas y clarificando las responsabilidades, un proveedor de servicios de nube puede garantizar que todos los suministradores que contribuyen a una aplicación saben qué necesitan suministrar para poder cumplir las expectativas de calidad de servicio de los clientes.